Modular specification of frame properties in JML

ion. The only restriction is that the field names of the dependees must be specified in the depends clauses. 5.1.2.2. Locality Rule. The locality rule is fairly natural: Usually, abstractions of dynamic components abstract from the states of their interface and representation objects. As long as these objects are reachable from an interface object via read-write references, such abstractions meet the locality requirement. Objects that are only reachable via readonly references can be seen as arguments of a dynamic component (e.g., the elements in a container). It seems widely accepted that abstractions of a dynamic component must not depend on the states of its arguments (see e.g., the arg mode in [5]). 5.1.2.3. Authenticity. Of all modularity requirements, authenticity entails the most onerous restrictions: (1) Authenticity forces programmers to use rep types whenever a type declaration declares a dependency where the field of the dependee is declared in an imported module. In such situations, all restrictions of the universe type system (see above) apply. (2) Because of authenticity, it is not possible for a location L declared in class C to depend on a location K of the same object if K’s declaration is inherited by C and contained in a different module. Otherwise, K and L would belong to the same context, but L’s declaration was not visible for the declaration of K. Therefore, authenticity does not fully support inheritance. This problem occurs also in different approaches [17] and is not solved yet. In many class libraries, such as the Java API, superand subclass are often declared in what would be the same module in our technique, and could be handled by our technique; but this would not help users of such a framework to make subclasses outside these modules. However, we need to refine our module system to deal with Java’s package concept before this can be studied in detail.